Conventional systems that perform data transfers typically use a protocol stack to facilitate the data transfer. A "protocol stack," also known as a protocol suite, contains a number of layers, with each layer responsible for a different facet of the data transfer. Each layer typically utilizes a protocol, which defines the types and formats of messages transferred by a layer to perform its facet of the data transfer.
A data transfer typically occurs between two end systems: the source of the data and the destination for the data. Often, the end systems are not directly connected, so the data transferred between the end systems must be routed through a number of intermediate systems. Each end system typically has the same protocol stack, although the intermediate systems need only a subset of the protocol stack that includes the layers necessary to perform the routing.
FIG. 1 depicts a protocol stack 100, known as the TCP/IP protocol stack, which has been used extensively by data transfer systems. For example, many systems on the Internet utilize a TCP/IP stack. One of the benefits of utilizing a TCP/IP stack is the ability to communicate in an easy, efficient, and standardized manner with many computers world wide. The TCP/IP protocol stack 100 comprises an application layer 102, a transport layer 104, a network layer 106, and a link layer 108. The application layer 102 performs the processing of a particular application. For example, the application layer 102 may provide file transfer functionality, electronic mail functionality, network management functionality, or remote log-in functionality. When performing one of these applications, the application layer 102 on one end system sends data to a corresponding application layer on another end system by passing the data to the transport layer 104.
The transport layer 104 receives data from the application layer 102 and facilitates the flow of this data between the application layers on the end systems. In the TCP/IP protocol stack 100, two different transport protocols are used: the transmission control protocol (TCP) and the user datagram protocol (UDP). TCP is a connection-oriented protocol that reliably transfers data between two end systems (a source and a destination). Before transferring data, the TCP layer on the source system establishes a connection with the TCP layer on the destination system, and the TCP layers send all of the packets to be transferred over this connection. As a result, TCP is known as a connection-oriented protocol. A connection-oriented protocol is one in which a connection is established before a data transfer occurs. A connection is established when the two ends of the connection have expressed an explicit willingness to take part in the data transfer. In a connection-oriented protocol, all data is transferred over a connection, and the connection is terminated after the data transfer has completed.
The data transfer performed by TCP is reliable because TCP guarantees that the data will be sent correctly to the destination end system. To provide such reliability, TCP (1) divides the data received from the application layer 102 into appropriately sized packets for the network layer 106, (2) acknowledges all packets received, (3) sets time-outs to ensure that the destination end system acknowledges that the packets were received, and (4) performs other functionality to ensure that when TCP receives data from the application layer 102, the corresponding TCP layer on the destination end system receives that data correctly. One drawback to TCP's reliable data transfer is, to perform this functionality, the size of the TCP layer is large, thus requiring a significant amount of memory.
In contrast to TCP, UDP is a much simpler service that provides unreliable data transfer. UDP is a connectionless protocol in which data is transferred in an unplanned fashion and without prior coordination. Upon receiving data from the application layer 102, UDP forms a packet, known as a datagram, and sends this packet to the network layer 106 for transfer to the end system in an unreliable manner: no acknowledgments are used and UDP does not guarantee that the datagrams reach the end system. UDP thus performs less functionality than TCP and, consequently, requires less memory.
The network layer 106, also known as the internet layer, receives packets from the transport layer 104 and performs the processing necessary to route these packets through the network. In the TCP/IP protocol stack 100, this layer utilizes one of three well-known protocols: the internet protocol (IP), the internet control message protocol (ICMP), or the internet group management protocol (IGMP).
The link layer 108, also known as the data-link layer or the network-interface layer, receives packets from the network layer 106 and performs the processing necessary to physically interface with the network transfer media, such as a cable, to transfer the packets across the network. To interface with the network transfer media, the link layer typically includes a network interface card and a suitable device driver that resides in the operating system.
The TCP/IP protocol stack 100 is utilized to transfer data within either a single network or within an internetwork ("internet"), which is a collection of networks using the same protocol stack. Each addressable entity, such as an application program, that can be accessed via the TCP/IP protocol stack has an associated IP address: the IP address is a 32-bit address specifying both a host ID (the ID of the computer on which the resource is located) and a network ID (the ID of the network on which the computer is located). IP addresses and, more generally, the TCP/IP protocol stack 100 is described in greater detail in Stevens, TCP/IP Illustrated Volume 1, Addison Wesley (1994), at pages 1-51, 143-168, and 223-337.
Although the TCP/IP protocol stack facilitates communication between systems, some systems are unable to utilize the TCP/IP stack and are thus unable to reap the benefits of efficiently communicating with numerous systems and devices in a standardized manner with relative simplicity. For example, hand-held devices, devices that can both be easily held and manipulated using one or two hands, have been developed for reading bar codes. These devices receive bar-code information and transmit it to a host computer via radio communications. Such devices can greatly benefit from using a TCP/IP protocol stack to facilitate communications to the host and other computers in a standardized manner using standard components. However, these devices have an extremely limited amount of memory. When selecting a transport layer for such a device, the TCP layer cannot be used because it is too large, thus requiring an unacceptable amount of memory. Likewise, the UDP layer cannot be utilized, because it provides unreliable communication, and the application on the hand-held device typically lacks the sophistication necessary to identify which datagrams have not been received, to keep track of these datagrams, and then to retransmit them when necessary. It is thus desirable to overcome these problems and to incorporate a TCP/IP protocol stack into a hand-held device.
Another problem that needs to be addressed in a communications system for a hand-held device is faulty communications. When a user utilizes a hand-held device, the user typically encounters interference, moves out of range, or performs some other action that disrupts communications, which causes a connection to terminate. Conventional connection-oriented protocol stacks, however, are not suitable for such an environment, because these protocol stacks require that an application program both maintain a copy of the data (i.e., packets) to be transferred in case the connection terminates and identify which packets were not transferred before the connection terminated. Having to perform this functionality increases the amount of memory needed by the application program as well as its complexity. When a connection terminates, conventional connection-oriented protocol stacks discard information associated with the connection, including both the packets that were to be transferred before the connection terminated as well as various context information, which is information associated with the connection, like an identifier of the destination, sequence numbers for the packets being transferred, and an indication of which packets were successfully transferred. As a result, when a connection terminates, the application program must identify which packets were not transferred before the connection terminated and must provide the protocol stack with these packets, so that the packets can be transferred.
To better illustrate this problem, FIG. 2 depicts a flowchart of the steps performed when a conventional, connection-oriented protocol layer (TCP) sends data between an application program on a source device and an application program on a destination device. The processing of both the source device and the destination device in this flowchart is depicted chronologically. The first step performed is that the application program on the source device provides a number of packets (e.g., A, B, C) to the TCP layer (step 202). After receiving these packets, the TCP layer sends packet A to the destination device (step 204). The TCP layer on the destination device, then receives packet A and responds by sending an acknowledgment to the TCP layer on the source device (step 206). After the TCP layer on the destination device sends the acknowledgment, the TCP layer on the source device receives the acknowledgment (step 207). Sometime after the TCP layer on the source device receives the acknowledgment, the connection terminates or disconnects (steps 208 and 210). A disconnect may occur, for example, when either the TCP layer on the source device or the TCP layer on the destination device explicitly requests a disconnect or if a communications error disrupts communications for more than a predetermined amount of time.
When the TCP layer on both the source device and the destination device determine that a disconnect occurred, the TCP layers discard all information associated with the connection and return an indication of the disconnect to their respective application program (steps 212 and 213). In these steps, for example, the TCP layer on the source device discards packets B and C and any indication that packet A was transferred successfully. Therefore, the application program on the source device must restart the data transfer by invoking the TCP layer on the source device and by passing packets B and C to the TCP layer (step 214). For the application program on the source device to be able to perform this functionality, the application program must have retained a copy of packets B and C after these packets were passed to the TCP layer in step 202, and the application program must keep track of which packets were transferred successfully. When the application program maintains a copy of a packet after the TCP layer receives a copy of the packet, the source device contains two copies of the same data. Maintaining two copies of data is sometimes referred to as double buffering. Although double buffering increases memory utilization, it does not typically pose a problem in larger computers; it does, however, pose a problem in smaller devices having limited memory, such as hand-held devices. Also, because the application program must keep track of which packets were transferred successfully, the complexity of the application program is increased. As a result of these drawbacks, it is desirable to improve communications in hand-held devices.